A set of services may be accessed via a network by application program interfaces (APIs) using standard protocols. A delivery model for the set of services may use different service architectures, different uniform resource indicators (URIs), and may be hosted in different geographically distributed data centers. The delivery model has a number of disadvantages, such as:
forcing developers to understand multiple URIs;
making geographic scaling of API services difficult;
lack of flexibility with respect to enabling additional services to onboard new APIs;
making scaling in a cost-effective manner difficult; and
making access to markets difficult where network performance is poor.
Further, when user data is stored and managed in multiple vertical services in multiple data centers, optimization of Create, Retrieve, Update, Delete (CRUD) operations over the user data, through APIs, may be a challenging problem. The problem may be addressed, in most services, by using a subdomain style URI mapped directly to a particular service through a Domain Name System (DNS) and segmenting the APIs by particular service names. However, consumers who do not understand the segmenting of the APIs may not be able to use the services. That is, without a knowledge of seams of the services, a developer cannot develop programs to make use of the services.